EBSスナップショットからのレストア

渡辺です。 今年の11月の北海道は暖かく、スキー場に雪が降ってもレストア（雪解け）してしまいます（T_T

運用設計時、バックアップは検討しているにも関わらず、レストア手順の検討を行っていないケースは稀によくあります。 最悪、バックアップ（EBSのスナップショット取得）さえしておけば何とかなるといえばなんとかなるのですが、レストアが必要な場合に焦らないよう、レストア手順はしっかりと押さえておくべきでしょう。 今回は、EBSのスナップショットからのレストア方法について３パターン紹介します。

新規インスタンスを作成してのレストア

ひとつ目の方法は、EBSスナップショットからAMIを作成し、そのAMIからEC2インスタンスを新規に作成する方法です。 AMIを作成する手間はありますが、元インスタンスを残したままにレストアできるため、レストア失敗時のリスクが最小に抑えられること、元インスタンスからのデータ移行も比較的楽な点がメリットです。

デメリットとしては、Private IP固定で構成している場合、旧インスタンスを完全に削除してからでなければ、同じPrivate IPを持った新規インスタンスを作れないことです。 一端、別のPrivate IPで作成してから変更といった方法もとれないので、固定Private IPの場合は注意してください。

手順

はじめにAMIを作成します。 スナップショットからレストア対象のスナップショットを選択し、アクションの「イメージ作成」を選択します。

イメージ名を適当に付けます（例: ami-for-restore）。

イメージが作成できたならば、AMIから対象のイメージを選択し、アクションの「作成」を選択してください。

後は通常のEC2インスタンスの作成手順に従えば、EC2インスタンスごとレストアすることができます。 インスタンスが起動したならば、EIPを差し替えるなどの方法で、新インスタンスを利用してください。

補足

レストアが完了したならば、イメージは基本的に不要です。 無駄なコストもちりが積もれば大きくなりますので、削除することを忘れずに。

また、新規EC2インスタンスとして作成する場合、インスタンスタイプなどインスタンスの属性も一緒に変更する事ができます。

ルートボリュームEBSの差しかえによるレストア

ふたつ目の方法は、EC2は同じインスタンスを利用し、EBSのルートボリュームのみを差し替える方法です。 新規インスタンスを作成する場合とは異なり、インスタンスを一度停止しなければなりません。 一方で、固定Private IPの場合でも、インスタンスはそのまま使い回すので問題なくレストア可能です。

手順

はじめにEBSボリュームを作成します。 スナップショットからレストア対象のスナップショットを選択し、アクションの「ボリューム作成」を選択します。

EBSボリュームを作成する時、注意したいのはAZを指定しなければならない点です。 レストア対象のEC2インスタンスがあるAZを選択してください。 異なるAZにあるEBSボリュームはEC2インスタンスにアタッチできません。

EBSボリュームの作成が出来たならば、EC2インスタンスのルートボリュームに設定します。 元のEBSボリュームをデタッチし、新しく作成したEBSボリュームをアタッチしますが、作業の前にEC2インスタンスを停止します。

ボリュームをアタッチする時は、対象のインスタンスを指定し、デバイスにルートボリュームを指定してください（Linuxであれば、/dev/xvda）。

アタッチが完了したならばEC2インスタンスを起動します。

EBSボリュームからのファイル単位のレストア

今回紹介する最後の方法は、EC2インスタンスとルートボリュームEBSはそのままとし、スナップショットからEBSボリュームを作成し、データの一部のみをレストアする方法です。 データの一部のみをバックアップから復元したい場合に有効な方法ですが、万が一、イメージからの起動やルートボリュームの差しかえでインスタンスが起動出来ない場合のレストア手順となるので覚えておくと良いでしょう。

手順

はじめにEBSボリューム差しかえの場合と同様に、EBSボリュームを作成します。

EBSボリュームを作成したならば、対象のEC2インスタンスにアタッチしてください。 今回はルートボリュームでないため、EC2インスタンスを停止する必要はありません（例: /dev/xvdf）。

EBSボリュームをアタッチしたならば、SSHログインを行い、EBSボリュームをマウントします。

$ sudo mkdir /backup
$ sudo mount /dev/xvdf1 /backup

AmazonLinuxであれば特に気にする点などはありませんが、他のOSの場合はマウント時に幾つか追加の操作が必要になるケースもあります。 EBSボリュームがマウントできたならば、rsyncやcpコマンドを使ってファイル単位でレストアしましょう。

補足

EBSボリューム（デバイス）のUUIDが重複し、マウントに失敗する場合は、以下のオプションを試してみてください。

$ sudo mount -nouuid /dev/xvdf /backup

スナップショットからのレストア時の注意点

EC2インスタンスを起動したままで取得したスナップショットからルートボリュームをレストアする場合、稀にインスタンスの起動ができないことがあります。 これは障害というよりも、リカバリできない中途半端なトランザクションなどがある状態のスナップショットであるのが原因です。 こればかりは、インスタンスを停止するか全サービスを停止してスナップショットを取得する以外に避方法はありません。

とはいえ、起動できないケースは稀です。 起動できない場合でも、基本的にマウントしてアクセスすることは出来るのでは最後の「EBSボリュームからのファイル単位のレストア」方法でデータを移行することで解決しましょう。

まとめ

バックアップ（スナップショット）からのレストア手順としては、EBSボリュームの作成が基本となります。 この時、EC2インスタンスごと作成する方法、EC2インスタンスのルートボリュームを差し替える方法、追加ボリュームとしてマウントする方法が選択できます。 なお、EBSボリュームを復元する場合は、EC2インスタンスがどのAZで稼動しているかを確認し、同一AZに作ることを忘れないでください。